perm filename MSG.MSG[X3,LSP]6 blob
sn#833014 filedate 1987-01-22 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂09-Oct-86 0616 jjohnson@mitre.ARPA ANSI X3J13 committee
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 9 Oct 86 06:15:52 PDT
Date: Thu, 9 Oct 86 09:14:26 edt
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8610091314.AA20136@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: common-lisp-request@su-ai.ARPA, mathis@b.isi.edu, rpg@sail.stanford.edu,
x3j13@sail.stanford.edu
Subject: ANSI X3J13 committee
Cc: jjohnson@mitre.ARPA
Greetings to all recipients of this message. I would appreciate your including
me on any correspondence concerning the standardization of Common Lisp within
ANSI and any other countries contributions to this ISO effort since I
am MITRE's representative on the X3J13 committee.
Sincerely,
Jerry Johnson
MITRE Corporation
AI Center
Mail Stop W418
1820 Dolley Madison Blvd
McLean, VA 22102
703-883-7173
∂09-Oct-86 1136 RPG Greetings
To: x3j13@SAIL.STANFORD.EDU
I am sending this message to reassure you that the X3J13
mailing list exists. The net address is:
x3j13@sail.stanford.edu
and the request address is
x3j13-request@sail.stanford.edu
-rpg-
∂10-Oct-86 1547 @REAGAN.AI.MIT.EDU:Hewitt@XX.LCS.MIT.EDU Meeting conflict
Received: from REAGAN.AI.MIT.EDU by SAIL.STANFORD.EDU with TCP; 10 Oct 86 15:47:04 PDT
Received: from DUE-PROCESS.AI.MIT.EDU by REAGAN.AI.MIT.EDU via CHAOS with CHAOS-MAIL id 6231; Fri 10-Oct-86 18:44:00 EDT
Date: Fri, 10 Oct 86 18:44 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: Meeting conflict
To: x3j13@SAIL.STANFORD.EDU
cc: Hewitt@XX.LCS.MIT.EDU
Message-ID: <861010184419.6.HEWITT@DUE-PROCESS.AI.MIT.EDU>
Folks,
I will be able to attend the next meeting on December 10 and 11 but not Dec.
12 because I have two scheduling conflicts on the 12th (it's my birthday and I
have to be present at another conflicting meeting on Friday the 12th).
--Carl
∂27-Oct-86 0653 MATHIS@ADA20.ISI.EDU X3J13 Meeting Dallas Dec 10-12
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 27 Oct 86 06:53:28 PST
Date: 27 Oct 1986 06:30-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: X3J13 Meeting Dallas Dec 10-12
From: MATHIS@ADA20.ISI.EDU
To: X3J13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]27-Oct-86 06:30:46.MATHIS>
The second meeting of X3J13 will be held from 1pm, Wednesday,
December 10, 1986, until noon, Friday, December 12, 1986, at the
Sheraton Park Central in Dallas, Texas. Arrangements have been
made by Ellen Waldrum of Texas Instruments.
Many aspects of these early meetings are attempts to determine
the best things for this committee. There was some feeling that
this three day format was better than a two day format from both
travel and work perspectives. Having the meeting in a hotel makes
somethings easier, but it also makes the meal service more
expensive. TI graciously offered to help offset some of these
costs, but I thought that was the wrong precedent to be setting.
At the first meeting, it seemed that most people brought lunches
back to the meeting room so they could keep discussing various
issues; that is why we arranged a lunch for Thursday. At every
other TI sponsored meeting I have ever attended (once before)
there was an informal dinner (everyone ordering from the menu and
paying their own) at the Trail Dust (which is good and very
informal). We could make these arrangements for Wednesday night.
All of these food arrangements are optional.
Other aspects of the meeting (agenda, discussion papers, etc.)
will be covered in subsequent messages. -- Bob Mathis
The following is from Ellen Waldrum:
X3J13 December Meeting Registration Form; mail to:
Beverly Williams
Texas Instruments
P.O. Box 655474
MS 3651
Dallas, Texas 75265
A block of rooms is available at the Sheraton Park Central. The
rate will be $60 a night (plus tax). Please check the
appropriate dates and supply a credit card number if you wish to
have the room guaranteed. Coffee, juice, breakfast rolls, and
fruit will be available for the morning sessions and coffee and
soft drinks will be available for the afternoon sessions. Lunch
has been arranged for the Dec. 11 meeting. The cost per person
for this food service is $25. Please include a check for this
amount with the registration form if you wish to partake. Delta
Airlines has agreed to give participants a 40% discount.
Unfortunately, the reference number needed for reservations is
not available yet. It will be posted to the X3J13 mailing list
as soon as it is known. There has been some interest expressed
in having a group dinner at the Trail Dust the evening of Dec.
10 with an extra cost. If enough people want to participate,
reservations will be made. If you are interested, please note
this in the appropriate space below. If you have questions about
room or airline reservations, please call Beverly at
214-997-2108. Questions of a more general nature about the
arrangements should be directed to Ellen Waldrum at 214-995-6716
or net mail address Waldrum%TI-CSL@CSNET-RELAY.
Name:
------------------------------------------------------
Institution:
----------------------------------------------
Street Address:
--------------------------------------------
City: State: Phone:
----------------- ---- ----------------
Reservations: Dec. 9: Dec. 10: Dec. 11:
----- ----- -----
Credit Card: AE MC Visa Number:
--- --- --- ---------------------
Food Service: Yes No
--- ---
(Please make check payable to Texas Instruments)
Dinner at Trail Dust: Yes No
---- ----
The room rate is only guaranteed for reservations made before
November 17 so please mail this form as soon as possible.
∂05-Nov-86 0723 MATHIS@ADA20.ISI.EDU x3j13 second mailing
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Nov 86 07:23:18 PST
Date: 5 Nov 1986 07:14-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: x3j13 second mailing
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Cc: Mathis@ADA20.ISI.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Nov-86 07:14:06.MATHIS>
I just sent out in US mail the second x3j13 mailing. In it I
said you should also have seen it on this electronic address.
Due to a computer problem (which you don't want to hearabout) I
am unable to send you the total information electronically; I am
however still able to communicate somewhat on the net.
If you have anything you want sent out before the next meeting I
should have it by November 14. In this case hardcopy that I
could photocopy would be helpful.
Remember to send in your hotel reservations for the Dallas
meeting.
-- Bob
∂14-Nov-86 1137 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Delta reference number
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:55 PST
Received: from ti-csl by csnet-relay.csnet id af01601; 13 Nov 86 8:10 EST
Received: from Puff (puff.ARPA) by tilde id AA04521; Wed, 12 Nov 86 16:05:10 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: Delta reference number
Date: 12-Nov-86 15:59:39
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741205578@Puff>
I had just sent the previous message when my phone rang.
Of course it was Beverly calling with the number I had
just told you was not available yet. To take advantage
of the Delta Airlines discount, you must make your
reservations through the Delta convention desk. The
phone number is 800-241-6760 and the reference file
number is B0238. We are listed with them as the
Computer Science Show. This discount is only good for
reservations made at least seven days in advance and
there are no penalties for cancellation. If you have
any questions or problems, please call Beverly or me
or send mail (Waldrum%ti-csl@csnet-relay).
-- Ellen
∂14-Nov-86 1136 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET December Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 14 Nov 86 11:36:26 PST
Received: from ti-csl by csnet-relay.csnet id ae01601; 13 Nov 86 8:08 EST
Received: from Puff (puff.ARPA) by tilde id AA03964; Wed, 12 Nov 86 15:49:14 cst
To: x3j13@SU-AI.ARPA
Cc: waldrum%ti-csl.csnet@RELAY.CS.NET
Subject: December Meeting
Date: 12-Nov-86 15:43:45
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2741204624@Puff>
If you are not able to mail your form in time to meet the
November 17 deadline and wish to make a reservation, you
should call Beverly Johnson at 214-997-2108 and give her
the pertinent information. If you do call Beverly, please
send the form anyway as verification.
The Delta airlines reference number is still not available.
All of the paperwork is done but Delta has not provided this
bit of pertinent information yet. It will be posted as soon
as we get it and Beverly will be calling those of you who have
already inquired.
-- Ellen
∂25-Nov-86 1302 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Reservation confirmation
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 25 Nov 86 13:02:34 PST
Received: from ti-csl by csnet-relay.csnet id ad04601; 25 Nov 86 15:42 EST
Received: from Puff (puff.ARPA) by tilde id AA23037; Tue, 25 Nov 86 13:32:15 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Reservation confirmation
Date: 25-Nov-86 13:28:28
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742319706@Puff>
I have received reservation forms from the following
people:
Beckerle, Michael Hadden, George
Boelk, Mary Haflich, Steve
Brown, Gary Hewitt, Carl
Cugini, John Kiczales, Gregor
Daniels, Andrew Loeffler, David
Dussud, Patrick Margolin, Barry
Dabrowski, Christopher Perdue, Crispin
Ennis, Susan Rand, Douglas
Fahlman, Scott Rosenking, Jeffrey
Foderaro, John Wegman, Mark
Gabriel, Richard Wieland, Alexis
The following people have made reservations by phone
but the form has not yet arrived:
Beman, Richard Moon, David
Clinger, Will Vandeusen, Mary
Goldstein, Brad Weinreb, Dan
Masinter, Larry White, Jon
If your name is not in one of these lists and you
think it should be, please let me know ASAP.
Thanks,
Ellen
Waldrum%ti-csl@csnet-relay
214-995-6716
P.S. I will have receipts for the checks available
at the meeting.
∂27-Nov-86 1355 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Additional reservations
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 27 Nov 86 13:55:32 PST
Received: from ti-csl by csnet-relay.csnet id bz12469; 27 Nov 86 16:45 EST
Received: from Puff (puff.ARPA) by tilde id AA09163; Wed, 26 Nov 86 15:41:43 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Additional reservations
Date: 26-Nov-86 15:36:49
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2742413804@Puff>
When I send the original list of reservations, a
few names were inadvertently omitted. The following
people have also made phone reservations, but the
paperwork has not yet arrived:
Antonisse, James
Bobrow, Danny
Chaihalloux, Jerome
Giansiracusa, Bob
Mathis, Bob
Ohlander, Ron
Pitman, Kent
Steele, Guy
I have received a reservation form from Mary Van Deusen.
-- Ellen
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU meeting in Dallas
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:15 PST
Date: 5 Dec 1986 11:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: meeting in Dallas
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:46:24.MATHIS>
I have just sent out some last minute documents. I hope that you
have all made your arrangements. Two messages follow: first is
cover letter on that mailing; second is draft agenda outline. If
you have any questions or comments, please be in touch. -- Bob
∂05-Dec-86 1734 MATHIS@ADA20.ISI.EDU Dallas meeting draft agenda outline
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:34:02 PST
Date: 5 Dec 1986 12:00-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting draft agenda outline
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 12:00:32.MATHIS>
agenda header -- 1
1 Call to Order, December 10, 1:00pm
2 Opening Remarks and Introductions
3 Approval of Agenda
4 Approval of Minutes of Sept 23-24 Meeting (Doc: 86-???)
5 Report on International Activities (Doc: 86-017)
6 Other Liaison Reports
7 Review of Goals and Objectives (Doc: 86-005)
8 Brief Overview of Technical Topics on Agenda
9 Recess, 5:00pm
agenda header -- 2
10 Call to Order, December 11, 9:00am
11 Function/Value Cells (Doc: 86-010)
12 Relationship of Common Lisp and Scheme
13 European approach to defining via levels
14 LUNCH Second Day, 12:00-1:00pm
15 Error Systems (Doc: 86-011, 86-012, 86-013, 86-014)
16 Update on object system discussions (Doc: 86-018)
17 Handling technical discussions
18 Recess, 5:00pm
agenda header -- 3
19 Call to Order, December 12, 9:00am
20 Summary of Technical Issues and Discussions
21 Planning Relative to Other Technical Issues
22 Call for Officer Candidates
23 Future Meeting Schedule (Doc: SD-04)
24 Review of Action Item Assignments
25 Adjournment, 12:00noon
∂05-Dec-86 1733 MATHIS@ADA20.ISI.EDU third mailing cover letter
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 17:33:25 PST
Date: 5 Dec 1986 11:56-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: third mailing cover letter
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU] 5-Dec-86 11:56:16.MATHIS>
Doc. No.: X3J13/86-015
Date: December 1, 1986
Project: X3J13 Common Lisp
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
Ph: (703)425-5923
Mathis
X3J13 Members, alternates, observers, and potential participants:
This is a last minute reminder of the next meeting in Dallas on
December 10-12, 1986. If you have yet to make your reservations,
call Beverly at TI at (214)997-2108 or for general information,
Ellen Waldrum at (214)995-6716.
1. The minutes of first meeting have been delayed due to an
unforeseen sequence of unforeseeable circumstances which should
have been predictable. They are promised for the meeting in
Dallas.
2. Enclosed with this letter are the preliminary papers on
function cells and error systems.
3. At the ISO/TC97/SC22 Advisory Group meeting in Vienna, it was
decided to move ahead for a new work item on Lisp with a convenor
coming from France and a project editor coming from the United
States. This will be an item for discussion at the Dallas
meeting.
4. I had the opportunity to meet with Cathie Kachurik of the X3
Secretariat and Gary Robinson of DEC (who also happens to be
quite active in X3 and ISO/TC97) about the use of the Steele book
as a basis for the eventual standard. This issue was the basis
for some motions at the last meeting, which at the current time
are out of order. In our general discussions of goals and
objectives for the X3J13 committee, we need to discuss the actual
form we envision for the eventual standard and how closely it may
be related to the Steele book or to other manuals which have been
developed by other companies.
5. Remember that after this second meeting, we will have to
propose to X3 a set of officer candidates for X3J13. If anybody
wants to serve they should be prepared to make it known at this
meeting.
6. There will be a detailed proposed agenda at the start of the
meeting, but for your planning: Wednesday afternoon will include
brief overviews of the various topics on the agenda and an
extended discussion of goals and objectives for X3J13; Thursday
morning will begin with the function/value cell discussion;
Thursday afternoon will begin with the error system discussion;
and Friday morning will be devoted to finishing up remaining
topics.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
Attachments:
X3J13/86-010 "Issues of Separation in Function Cells and Value
Cells" by Gabriel and Pitman with others
X3J13/86-011 "Exceptional Situations in Lisp" by Pitman
X3J13/86-012 "Error Proposal #8 as of 8/4/86" by Pitman
X3J13/86-013 "Error Proposal #8 implementation suggestion as
of 8/4/86" by Pitman
X3J13/86-014 "Error Proposal Feedback up to 11/19/86"
∂05-Dec-86 1825 FAHLMAN@C.CS.CMU.EDU Logisitcs for Dallas meeting
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 5 Dec 86 18:25:39 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 5 Dec 86 21:25:36-EST
Date: Fri, 5 Dec 1986 21:25 EST
Message-ID: <FAHLMAN.12260501376.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: x3j13@SU-AI.ARPA
Subject: Logisitcs for Dallas meeting
I have a couple of questions about local arrangements for the Dallas
meeting. Could someone from TI send the following info to this mailing
list. (My apologies if this info was in some earlier mailing -- I can't
seem to find it if so. Maybe it was on the reservation form, which I
mailed in and didn't copy.)
1. Mailing address and phone number of the Sheraton Park Central.
2. How to get there from DFW airport. Approximate price and time
required for a taxi. Is there any cheaper way to make the trip, such as
a hotel limo? A lot of us will probably be arriving 10 - noon on
Wednesday, and will be heading back to the airport after adjornment on
Friday.
Thanks,
Scott
∂08-Dec-86 0902 jjohnson@mitre.ARPA Re: meeting in Dallas
Received: from MITRE.ARPA by SAIL.STANFORD.EDU with TCP; 8 Dec 86 09:00:46 PST
Date: Mon, 8 Dec 86 11:50:17 est
From: jjohnson@mitre.ARPA (Jerry Johnson)
Full-Name: Jerry Johnson
Message-Id: <8612081650.AA17339@mitre.ARPA>
Organization: The MITRE Corp., Washington, D.C.
To: MATHIS@ADA20.ISI.EDU, x3j13@SU-AI.ARPA
Subject: Re: meeting in Dallas
Bob
My new mailing address is
Jerry Johnson
MITRE Corp
Mail Stop W418
1820 Dolley Madison Blvd
McLean VA 22102
Jerry
∂10-Dec-86 0358 ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET Logistics for Dallas Meeting
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 10 Dec 86 03:57:48 PST
Received: from ti-csl by csnet-relay.csnet id ad02710; 10 Dec 86 6:34 EST
Received: from Puff (puff.ARPA) by tilde id AA00397; Mon, 8 Dec 86 17:37:01 cst
To: x3j13@SU-AI.ARPA
Cc: ellen%Puff%ti-csl.csnet@RELAY.CS.NET
Subject: Logistics for Dallas Meeting
Date: 8-Dec-86 16:50:13
From: ELLEN%Puff%ti-csl.csnet@RELAY.CS.NET
Message-Id: <ELLEN.2743455011@Puff>
Thanks for the suggestion, Scott.
The mailing address of the hotel is
Sheraton Park Central
12720 Merit Drive
Dallas, Texas 75251
and the phone number is 214-385-3000.
Taxi fare from DFW to the hotel should be
approximately $20. There is also a shuttle
service called The Link that charges $9.
The approximate travel time is 30 minutes.
-- Ellen
∂12-Dec-86 1900 MATHIS@ADA20.ISI.EDU Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 12 Dec 86 18:55:23 PST
Date: 12 Dec 1986 18:25-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SU-AI.ARPA
Message-ID: <[ADA20.ISI.EDU]12-Dec-86 18:25:14.MATHIS>
Thanks to everyone. I think we had a very productive meeting.
We have a lot of work to do in preparation for the March 16-18,
1987, meeting in Palo Alto. Let's keep the communication going.
Watch this space and help fill it. -- Bob Mathis
∂15-Dec-86 1630 RPG Contents of the X3J13 mailing list
To: x3j13@SAIL.STANFORD.EDU
Here they are:
rpg
#msg.msg[jnk,jmc]
hst
"uwmcsd1!marque!maxiv"@UNIX.MACC.WISC.EDU
coffee@AEROSPACE.ARPA
cugini@ICST-ECF
dabrowski@ICST-ECF
"J.Dalton%uk.ac.edinburgh"@CS.UCL.AC.UK
ffitch@RAND-UNIX
padget@RAND-UNIX
NGALL@BBNG.ARPA
"barmar%bco"@HI-MULTICS.ARPA
hadden@HI-MULTICS.ARPA
hemphill@NRL-AIC.ARPA
"uwmcsd1!marque!gregj"@RSCH.WISC.EDU
"fkunze%franz.uucp"@UCBVAX.Berkeley.EDU
"jkf%franz.uucp"@UCBVAX.Berkeley.EDU
"smh%franz.uucp"@UCBVAX.Berkeley.EDU
Baggins@IBM.COM
Brandon@IBM.COM
"marick%mycroft"@GSWD-VMS.ARPA
dougr@MIT-EDDIE.ARPA
"primerd!barryn"@MIT-EDDIE.ARPA
"mcvax!inria!chaillou"@seismo.CSS.GOV
"mcvax!inria!crcge1!neidl"@seismo.CSS.GOV
peck@SPAM.ISTC.SRI.COM
scherlis@VAX.DARPA.MIL
squires@VAX.DARPA.MIL
gls@ZARATHUSTRA.THINK.COM
Wegman@IBM.COM
antonisse@MITRE.ARPA
jjohnson@MITRE.ARPA
Wieland@MITRE.ARPA
Yonke@USC-ECL.ARPA
Ohlander@ISI.EDU
balzer@A.ISI.EDU
Mathis@A.ISI.EDU
berman@VAXA.ISI.EDU
masinter.pa@Xerox.COM
Adler.pa@XEROX.COM
Bobrow.pa@XEROX.COM
pavel.pa@XEROX.COM
daniels.pa@XEROX.COM
gregor.pa@XEROX.COM
Ricci.pa@XEROX.COM
Sye.pasa@XEROX.COM
vittal.pasa@XEROX.COM
"JerryB%OZ"@XX.LCS.MIT.EDU
Hewitt@XX.LCS.MIT.EDU
"willc%tekchips@tek.csnet"@RELAY.CS.NET
"sridhar%tekchips@tek.csnet"@RELAY.CS.NET
"angela%gmdtub.uucp@Germany.csnet"@RELAY.CS.NET
"Bartley%TI-CSL"@RELAY.CS.NET
"Bate%TI-CSL"@RELAY.CS.NET
"Dussud%AUSOME%TI-CSL"@RELAY.CS.NET
"ida%utokyo-relay.csnet"@RELAY.CS.NET
"Waldrum%TI-CSL"@RELAY.CS.NET
"TURBA%sperry-csd.csnet"@RELAY.CS.NET
bawden@MC.LCS.MIT.EDU
RG@MC.LCS.MIT.EDU
"mike%acorn"@LIVE-OAK.LCS.MIT.EDU
"RSG%OZ"@AI.AI.MIT.EDU
JAR@MC.LCS.MIT.EDU
Soley@MC.LCS.MIT.EDU
"edsel!eb"@NAVAJO.STANFORD.EDU
"edsel!jonl"@NAVAJO.STANFORD.EDU
"edsel!jlz"@NAVAJO.STANFORD.EDU
fahlman@C.CS.CMU.EDU
RAM@C.CS.CMU.EDU
sgadol@Sun.COM
Muchnick@Sun.COM
CPerdue@Sun.COM
"quintus!gehrig!bak"@Sun.COM
Moon@SCRC-STONY-BROOK.ARPA
KMP@SCRC-STONY-BROOK.ARPA
DLW@SCRC-STONY-BROOK.ARPA
Goldstein@SCRC-STONY-BROOK.ARPA
ACW@SCRC-STONY-BROOK.ARPA
chaowatkins@SCRC-STONY-BROOK.ARPA
griss@HPLABS.HP.COM
"DCM%HPFCLP"@HPLABS.HP.COM
chapin@hplabs.hp.com
Krall@MCC.COM
Loeffler@MCC.COM
"Brown%Bach.Dec.Com"@DECWRL.DEC.COM
slater@umbc2.umd.edu
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU minutes of Dallas meeting
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:53 PST
Date: 19 Dec 1986 05:51-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: minutes of Dallas meeting
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:51:46.MATHIS>
Gary Brown has already sent me the draft minutes of the Dallas
meeting. They seem very good, but he and I are still double
checking each other. If you want to see the preliminary version,
I will forward it to you; if you would rather wait, they will
come in about ten days. -- Bob Mathis
∂19-Dec-86 0608 MATHIS@ADA20.ISI.EDU proposed purposes
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 06:07:38 PST
Date: 19 Dec 1986 05:46-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes
Subject: [Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
sigh, sigh! Guy got this done, but to me on a day I was off the
net. He has inserted some sight additions. We should discuss
this on the net so that we can make a clean copy with clearly
specified alternate wordings so that we could vote on it point by
point at the next meeting. In Dallas I got the feeling that if
we had a clean text, it would probably be passed unanimously.
This is the chance for all of you (particularly those who could
not be in Dallas) to participate in the discussion. -- Bob
Mathis
Begin forwarded message
Received: FROM GODOT.THINK.COM BY USC-ISIF.ARPA WITH TCP ; 16 Dec 86 09:46:39 PST
from boethius by Godot.Think.COM via CHAOS; Tue, 16 Dec 86 12:45:00 EST
Date: Tue, 16 Dec 86 12:46 EST
From: Guy Steele <gls@Think.COM>
To: mathis@ada20.isi.edu
Cc: gls@AQUINAS
Subject: [gls@Think.COM: X3J13 charter (proposed)]
Return-Path: <gls@Think.COM>
Message-ID: <861216124628.6.GLS@BOETHIUS.THINK.COM>
Sigh. I mailed this Friday evening, but to the wrong address.
--Guy
----------------------------------------------------------------
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National
Standard for Common Lisp. It will codify existing practice,
provide extensions to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in
{\it Common Lisp: The Language} by Guy L. Steele Jr. (Digital
Press, 1984), which is the current {\it de facto} standard for
Common Lisp. Whenever there is a proposal for the standard to
differ from {\it Common Lisp: The Language}, the committee
shall weigh both future costs of adopting (or not adopting) a
change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in {\it Common Lisp: The Language}
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in {\it Common Lisp: The
Language} that require resolution. Topics (d) and (e) are not
addressed by {\it Common Lisp: The Language} but appear to be
well-understood and ready for standardization. Topics (f)-(i)
concern areas where standardization is desirable but not
crucial to production of a standard. Topic (j) is an area of
current controversy within the Lisp community. Other topics
may be considered if specific proposals are received.
4. The committee recognizes that Lisp programming practice
will continue to evolve and anticipates the need for future
revisions and extensions to the standard. This may include a
family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
[Possible amendment: change the word "extensions" in the first
paragraph to "additional features".]
--------------------
End forwarded message
∂19-Dec-86 0727 FAHLMAN@C.CS.CMU.EDU proposed purposes
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 07:27:45 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 19 Dec 86 10:26:34-EST
Date: Fri, 19 Dec 1986 10:26 EST
Message-ID: <FAHLMAN.12264051413.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: proposed purposes
In-reply-to: Msg of 19 Dec 1986 08:46-EST from MATHIS at ADA20.ISI.EDU
Looks excellent to me.
The proposed ammendment (extensions -> additional features), seems like
a useful clarification.
-- Scott
∂19-Dec-86 0831 Bobrow.pa@Xerox.COM Re: proposed purposes
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 19 Dec 86 08:31:04 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 DEC 86 08:31:11 PST
Date: 19 Dec 86 08:30 PST
Sender: Bobrow.pa@Xerox.COM
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: proposed purposes
In-reply-to: MATHIS@ADA20.ISI.EDU's message of 19 Dec 86 05:46 PST
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
Message-ID: <861219-083111-7132@Xerox>
I like this very much -- with the suggested change:
extensions --> additional features
It captures both the need for resolving the current set of issues
relatively quicly for the current community, and also possible futures
that could involve more work, but provide great benefit.
danny
∂19-Dec-86 0936 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:35:49 PST
Posted-Date: Fri 19 Dec 86 09:35:29-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22770; Fri, 19 Dec 86 09:35:30 PST
Date: Fri 19 Dec 86 09:35:29-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:35:29.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "additional
features" to "extensions".
Ron
-------
∂19-Dec-86 0958 ohlander@venera.isi.edu Re: proposed purposes
Received: from VENERA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 09:58:18 PST
Posted-Date: Fri 19 Dec 86 09:43:35-PST
Received: by venera.isi.edu (5.54/5.51)
id AA22910; Fri, 19 Dec 86 09:43:36 PST
Date: Fri 19 Dec 86 09:43:35-PST
From: Ron Ohlander <OHLANDER@venera.isi.edu>
Subject: Re: proposed purposes
To: MATHIS@ada20.isi.edu
Cc: X3J13@sail.stanford.edu
Message-Id: <VAX-MM(195)+TOPSLIB(124) 19-Dec-86 09:43:35.VENERA.ISI.EDU>
In-Reply-To: Message from "MATHIS@ADA20.ISI.EDU" of 19 Dec 1986 05:46-PST
Looks good. I vote for the document with the change of "extensions"
to "additional features."
Ron
-------
∂19-Dec-86 1155 berman@vaxa.isi.edu Re: proposed purposes,
Received: from VAXA.ISI.EDU by SAIL.STANFORD.EDU with TCP; 19 Dec 86 11:55:25 PST
Received: by vaxa.isi.edu (4.12/4.7)
id AA17572; Fri, 19 Dec 86 11:55:23 pst
From: berman@vaxa.isi.edu (Richard Berman)
Message-Id: <8612191955.AA17572@vaxa.isi.edu>
Date: 19 Dec 1986 1155-PST (Friday)
To: MATHIS@ADA20.ISI.EDU
Cc: x3j13@SAIL.STANFORD.EDU
Subject: Re: proposed purposes,
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
In-Reply-To: Your message of 19 Dec 1986 05:46-PST.
<[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Me Like. Ugh.
RB.
∂19-Dec-86 1323 DLW@ALDERAAN.SCRC.Symbolics.COM proposed purposes
Received: from [192.10.41.109] by SAIL.STANFORD.EDU with TCP; 19 Dec 86 13:19:50 PST
Received: from CHICOPEE.SCRC.Symbolics.COM by ALDERAAN.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 32441; Fri 19-Dec-86 15:52:55 EST
Date: Fri, 19 Dec 86 15:54 EST
From: Daniel L. Weinreb <DLW@ALDERAAN.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU, x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219155422.5.DLW@CHICOPEE.SCRC.Symbolics.COM>
This looks fine. The spelling of "ommissions" should omit one of the
m's. I agree that "extensions" should be changed to "additional
features".
∂19-Dec-86 2017 Moon@RIVERSIDE.SCRC.Symbolics.COM proposed purposes
Received: from SCRC-RIVERSIDE.ARPA by SAIL.STANFORD.EDU with TCP; 19 Dec 86 20:17:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 87742; Fri 19-Dec-86 23:15:26 EST
Date: Fri, 19 Dec 86 23:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: proposed purposes
[Guy Steele <gls@Think.COM>: [gls@Think.COM: X3J13 charter ...]
To: MATHIS@ADA20.ISI.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <[ADA20.ISI.EDU]19-Dec-86 05:46:27.MATHIS>
Message-ID: <861219231549.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I think this is an excellent charter for X3J13. I approve of the
wording and especially of the attitude about what is important and the
choice to finish Common Lisp rather than embarking on a new experiment.
One comment on "establish normative Common Lisp programming practice":
I doubt it's actually possible to get such a large group of Lisp programmers
to agree in any meaningful way on issues of programming style. If this
goal is achieved, it will be a monumental accomplishment. My preference
would be to leave it to the professors and the authors of textbooks, but
I have no real objection. After all, some of the lettered items will be
fairly difficult to bring to closure too.
∂22-Dec-86 1849 hpfclp!dcm@hplabs.HP.COM Charter statement
Received: from HPLABS.HP.COM by SAIL.STANFORD.EDU with TCP; 22 Dec 86 18:49:07 PST
Received: by hplabs.HP.COM ; Mon, 22 Dec 86 14:07:40 pst
From: hpfclp!dcm@hplabs.HP.COM
Received: by hpfclp; Mon, 22 Dec 86 10:24:52 mst
Date: Mon, 22 Dec 86 10:24:52 mst
Return-Path: <hpfclp!dcm>
Received: from hpfcdcm.UUCP; Mon, 22 Dec 86 10:15 MST
To: hpfclp!x3j13@sail.stanford.edu
Subject: Charter statement
This may have already appeared from another source, I'm not sure since there
seems to be some problem with my mail address. Here is the text of Guy's
statement of purpose with some comments from the discussions. Words or
clauses that were topics of discussion are enclosed in []s. Additional notes
are indented after each item.
Dave Matthews
------------------------------------------------------------------------------
Revise draft 86-005
Purposes of X3J13 Committee (proposed)
1. X3J13 is chartered to produce an American National Standard for Common Lisp.
It will codify existing practice, provide [extensions] [necessary] to
[facilitate] portability of code among diverse implementations and [establish]
normative [Common] Lisp programming practice.
change establish to stabilize?
extensions is a loaded word, are they required or not, maybe features is
a better word?
should a stronger term than facilitate be used
are we really establishing a programming practice, including style, etc
2. The committee will begin with the language described in Common Lisp: the
Language by Guy L. Steele Jr., which is the current de facto standard for
Common Lisp. Whenever there is a proposal for the standard to differ from CLTL
the committee shall weigh both future costs of adopting (or not adopting) a
[feature] and costs of conversion of existing code. [Aesthetic criteria shall
be a subordinate consideration.]
feature might be better said as change
should the clause about aesthetics exist at all
3. The committee will address at least the following topics in the course of
producing the standard, in each case either incorporating specific features or
explaining why no action was taken:
a) repairing [errors/mistakes], ambiguities and minor omissions in CLTL
b) error handling/condition signalling
c) semantics of compilation
d) object-oriented programming
e) iteration [the LOOP] constructs
f) multiprocessing
g) graphics
h) windows
i) one or two name spaces for functions or values
j) validation
Topics (a)-(c) concern deficiencies in CLTL that require resolution. Topics
(d) and (e) are not addressed by CLTL but appear to be well-understood and
ready for standardization. Topics (f)-(h) concern areas where standardization
is desirable but not crucial to production of a standard. Topic (i) is an
area of current controversy in the LISP community.
Topic (j) is not currently clarified.
4. The committee recognizes that Lisp programming practice will continue to
evolve, and anticipates the need for future revisions and extensions to the
standard. This may include a family of Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international Lisp standard.
separated from item 4.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU 2nd meeting minutes X3J13/86-021
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:05 PST
Date: 5 Jan 1987 17:12-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: 2nd meeting minutes X3J13/86-021
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:12:03.MATHIS>
DRAFT Minutes X3J13 Committee Meeting
Dates: December 10, 11, 12, 1986
Location: Sheraton Park Central Hotel, Dallas, Texas
Chair: Bob Mathis (acting)
Secretary: Gary Brown (acting)
Hour of opening: December 10, 1986 1:20 PM
Hour of adjournment: December 12, 1986 11:25 AM
List of Voting members: Attached
Approved Agenda: Attached (86-0016)
Approval of previous minutes: None were prepared
Register of Documents: Attached
Motions seconded and not withdrawn:
Motion to formally thank Ellen Waldrum and Texas Instruments for
the meeting arrangements.
Moved by Dave Slater
Seconded by Peter Coffee
Unanimously approved
Future meeting schedule:
The next meeting is scheduled for March 16, 17 and 18, 1987 in Palo
Alto, California. Dick Gabriel will make the arrangements.
List of action items assigned to committee members:
Working groups were formed for eleven areas requiring investigation
and a convenor was assigned for each group. These groups are
informally charged with bringing evaluation and recommendations back
to the full committee. The body of the minutes lists the groups
and their convenors.
Meeting Summary:
Call to Order:
The meeting was called to order at 1:20 PM.
Opening remarks:
Bob Mathis specified significant dates for X3J13:
December 30, 1986: Wrapup mailing for second meeting
January 9, 1987: Minutes for second meeting due
January 15, 1987: Membership fees due (however no one has
yet received bills)
February 4, 1987: Deadline for next meetings mailing
February 10, 1987: Mailing for meeting 3
Bob Mathis introduced himself discussed his background. All attendees
then introduced themselves.
Approval of agenda:
The agenda, X3J13/86-016, was approved without objection.
Approval of minutes:
The minutes of the first meeting (September 23-24) were not available.
Report on International Activities:
Bob Mathis attended SC22 in Vienna and reported on that meeting.
The major decision was that an ISO Lisp committee would be formed
with a convenor from France and a project editor from the United
States.
Dick Gabriel reported on the "EuLisp" meeting in Paris. The
"EuLisp" group intends to work through ISO and Christian Queinnec
would be group convenor. Several technical issues were also
discussed at the Paris meeting and it is obvious that there
are some technical differences between the initial "EuLisp"
proposal and Common Lisp.
Other liaisons reports:
Bob Mathis asked if there were any volunteers to review:
o Guidelines for programming language conformity and testing
o Programming language standards document standard (i.e. a standard
for how a standard should be written)
Mathis also reported that DEC Press would cooperate with X3J13 in
preparation of standards document. However, initial discussions
with ANSI on allowing the "free" distribution of the standard
document were not encouraging.
Review of Goals and Objectives (86-005):
Approximately an hour and a half was spent discussing the proposed
goal statement for X3J13. Issues raised included:
o the relationship between X3J13 and an ISO Lisp standard effort
o conservative vs ambitious planning and language design
o de-facto vs real standards
Various committee members contributed opinions and historical anecdotes.
No formal motions were made.
Overview of technical topics.
Dick Gabriel gave a brief overview of issues surrounding function
and value cell separation. Kent Pitman gave a overview of the
proposed condition handling system.
Recess:
The meeting was recessed on December 10, 1986 at 5:30 PM.
Call to Order:
The meeting was resumed on December 11, 1986 at 9:07 AM.
Function/Value Cells (86-010):
Dick Gabriel presented the technical issues raised in "Issues of
Separation in Function Cells and Value Cells" (86-010). This topic
was dsicussed for two and a half hours.
Lunch:
The meeting was recessed for lunch from 11:45 AM to 12:50 PM.
Goals and Objectives:
Danny Bobrow presented some alterations to the "Goals and Objectives".
These proposed changes included:
o Stating that X3J13 would work on two fronts; ANS standard for Common
Lisp and working with ISO to prodcue Lisp standard for the longer term.
o Stating we would address other areas such as windows, graphics and
multi-processing
Jerome Chailloux gave his opinions on the goals for X3J13.
Error Systems:
Kent Pitman presented a description of the proposed Common Lisp
Condition handling system. Discussions lasted an hour and fifteen
minutes. Kent believes this proposal is relatively firm and a
final specification will be available soon.
Update on object systems:
Danny Bobrow presented the status of the proposed Common Lisp
object subsystem. The major change between current design and
what was previously proposed is no longer using DEFSTRUCT for
object definition but instead using two new macros; DEFRECORD and
DEFCLASS. Danny believes that this work is progressing well and
expects convergence before the next meeting.
Goal and Objectives:
Approximately half an hour was spent in another open discussion
X3J13 of Goals and Objectives. Bob Mathis suggested that an
ANS standard separate from ISO might be rejected by X3.
Recess:
The meeting was recessed on December 11, 1986 at 5:15 PM.
Call to Order:
The meeting was resumed on December 12, 1986 at 9:10 AM.
The committee voted to formally thank Ellen Waldrum and Texas
Instruments for the meeting arrangements.
Handling Technical Issues:
Bill Scherlis reported on the reccommendations of a subgroup formed
to discuss effective ways for X3J13 to discuss and decide issues.
They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person speicified is
the acting chair for each group [other initial members are listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk, Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
Goal and Objectives:
Guy Steele presented the recommendation of a subgroup formed
to create another draft of the Goals and Objectives statement for
X3J13. Here is a draft of this document:
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
features to facilitate portability of code among diverse
implementations and establish normative Common Lisp practice.
2. The committee will begin with the language described in "Common
Lisp: the Language" by Guy L. Steele Jr., which is the current
"de facto" standard for Common Lisp. Whenever there is a
proposal for the Standard to differ from CLtL, the committee
shall weigh both future costs of adopting (or not adopting)
a change and costs of conversion of existing code. Aesthetic
criteria shall be a subordinate consideration.
3. The committee will address at least the following topics
in the course of producing the standard, in each case either
incorporating specific features or explaining why no action
was taken:
(a) Repairing mistakes, ambiguities and minor omissions in CLtL
(b) Error handling/condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration construct(s)
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) One or two namespaces for functions and values
(j) Validation
Topics (a)-(c) concern deficiencies in CLtL that require resolution.
Topics (d) and (e) are not addressed by CLtL but appear to be
well understood and ready for standarization. Topics (f)-(h)
concern areas where standarization is desirable but not crucial
to production of a standard. Topic (i) is an area of current
controversy within the Lisp community. Other topics may be
considered if specific proposals are received.
4. The comittee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
A discussion of this proposal took place followed by an informal
"sense of the committee" vote. The committee overwhelmingly
accepted this proposal. A final draft of this will be prepared
for a formal vote at the next meeting.
Call for officer candidates:
The following committee members are standing for X3J13 elected offices:
o Chair - Bob Mathis
o Vice-chair - Guy Steele
o International Representative - Dick Gabriel
Future meeting Schedule:
The next meeting will be March 16-18, 1987 in Palo Alto, California.
Adjournment:
The meeting was adjourned on December 12, 1986 at 11:25 AM.
Respectfully Submitted,
Gary L. Brown
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU proposed purposes X3J13/86-020
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:27:30 PST
Date: 5 Jan 1987 17:15-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: proposed purposes X3J13/86-020
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:15:45.MATHIS>
Purposes of X3J13 Committee (Proposed)
1. X3J13 is chartered to produce an American National Standard
for Common Lisp. It will codify existing practice, provide
extensions [amendment: change the word "extensions" to
"additional features".] to facilitate portability of code among
diverse implementations, and establish normative Common Lisp
programming practice.
2. The committee will begin with the language described in Common
Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984),
which is the current de facto standard for Common Lisp. Whenever
there is a proposal for the standard to differ from Common Lisp:
The Language, the committee shall weigh both future costs of
adopting (or not adopting) a change and costs of conversion of
existing code. Aesthetic criteria shall be a subordinate
consideration.
3. The committee will address at least the following topics in
the course of producing the standard, in each case either
incorporating specific features or explaining why no action was
taken:
(a) Repairing mistakes, ambiguities, and minor ommissions
in Common Lisp: The Language
(b) Error handling and condition signalling
(c) Semantics of compilation
(d) Object-oriented programming
(e) Iteration constructs
(f) Multiprocessing
(g) Graphics
(h) Windows
(i) Validation
(j) One versus two namespaces for functions and variables
Topics (a)-(c) concern deficiencies in Common Lisp: The Language
that require resolution. Topics (d) and (e) are not addressed by
Common Lisp: The Language, but appear to be well-understood and
ready for standardization. Topics (f)-(i) concern areas where
standardization is desirable but not crucial to production of a
standard. Topic (j) is an area of current controversy within the
Lisp community. Other topics may be considered if specific
proposals are received.
4. The committee recognizes that Lisp programming practice will
continue to evolve and anticipates the need for future revisions
and extensions to the standard. This may include a family of
Lisps and/or a layered Lisp model.
5. X3J13 is committed to work with ISO toward an international
Lisp standard.
∂05-Jan-87 1727 MATHIS@ADA20.ISI.EDU general letter X3J13/86-022
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 5 Jan 87 17:26:57 PST
Date: 5 Jan 1987 17:03-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: general letter X3J13/86-022
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 5-Jan-87 17:03:23.MATHIS>
Doc. No.: X3J13/86-022
Date: 86-12-30
Reply to:
Robert F. Mathis
9712 Ceralene Dr.
Fairfax, VA 22032
To everyone on the X3J13 (Common Lisp) mailing list:
This letter is being sent out in three different configurations: by
electronic mail to <x3j13> at SAIL (to everyone on that list), by regular
mail with enclosures (to everyone who has given an indication of
participation), and by regular mail without enclosures (to those on the
mailing list who have never responded). People who receive this letter
without enclosures, need to respond to this letter to remain on the mailing
list. Membership on X3J13 is open, but is based on a commitment to
continuing participation.
The Draft minutes of the Dallas meeting are enclosed (Doc: X3J13/86-021).
Thanks to Gary Brown. Included there is the list of initial members in the
task groups we formed (this was also the content of a separate electronic
message). Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed. At least part of the reason for
not forming the ISO interaction group was that the US delegation to the ISO
working group has not been chosen. Anyone from X3J13 is eligible if they
can make the additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation, please
contact me; Mathis, Gabriel, and Clinger have already expressed their
interest.
The acting chairs are to make sure that the members of their group
communicate with each other. If it is appropriate that a group set itself
an agenda and select a leader, the acting chair should make sure it
happens. Each of these groups will be called on for a BRIEF report at the
next meeting. If that report will be any more than just an affirmation of
existence, please contact me for scheduling.
As a separate document (Doc: X3J13/86-020) the draft proposed purposes are
also enclosed. This differs slightly from the version in the minutes; it is
X3J13/86-020 (or its revision) that we will be considering at the next
meeting. This has also been circulated electronically.
You (that is people who received enclosures with this letter or who respond
to this letter) will be sent the other documents resluting from the Dallas
meeting separately.
If you have any comments or other documents you want circulated before the
next meeting, please send them to me by February 4, 1987.
Sincerely yours,
Robert F. Mathis
Acting Chairman, X3J13
∂06-Jan-87 0723 MATHIS@ADA20.ISI.EDU task groups
Received: from ADA20.ISI.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 07:19:23 PST
Date: 6 Jan 1987 07:13-PST
Sender: MATHIS@ADA20.ISI.EDU
Subject: task groups
From: MATHIS@ADA20.ISI.EDU
To: x3j13@SAIL.STANFORD.EDU
Message-ID: <[ADA20.ISI.EDU] 6-Jan-87 07:13:41.MATHIS>
This has been covered in my over messages, but
is also being sent separately for emphasis.
-- Bob
At the meeting in Dallas, we decided to form some subgroups
(working groups, task groups, committees, or whatever name). What
follows is a section from the draft minutes giving the initial
structure of these groups. (Thanks to Gary Brown for getting the
minutes ready so promptly.) Others are free to join these groups,
but the size of each group should remain reasonable and
individuals should recognize they are making a commitment by
joining.
Bill Scherlis reported on the recommendations of a subgroup
formed to discuss effective ways for X3J13 to discuss and decide
issues. They suggested that small working groups be formed to:
o Prepare briefings for the entire committee
o Evaluate the costs and benefits of alternative
o Make recommendations for appropriate action.
The following task groups were suggested. The person specified is
the acting chair for each group [other initial members are
listed].
1. Steele book cleanup Scott Fahlman
[Matthews, Pitman, White, Maisinter, Steele]
2. Lisp1/Lisp2 Dick Gabriel
[Pitman, Clinger, Wegman, Giansiracusa, Weinreb]
3. Objects Danny Bobrow
[Gabriel, Moon, Dusaud, Gregor, Keen, DeMicale]
4. Errors and conditions Kent Pitman
[Daniels]
5. Validation and conformance Rich Berman
[Beckerle, Slater, White]
6. Types and declarations Bill Scherlis
[Curtis, Slater, Poser]
7. Macros Kent Pitman
[Haflich, Wegman]
8. Compiler specification Steve Haflich
[Beckerle, Bartly, MacLaughlin]
9. Presentation of standard Gary Brown
[Matthews, Lieberman, Ohlander, Rosenking, Boelk,
Ennis]
10. Graphics and windows Doug Rand
[Masinter, Hadden, Waldrum, Debrowski]
11. Iteration JonL White
[Weinreb, Perdue]
Groups to discuss multiprocessing, transition management and ISO
iteraction were proposed but not formed.
[At least part of the reason for not forming the ISO interaction
group was that the US delegation to the ISO working group has not
been chosen. Anyone from X3J13 is eligible if they can make the
additional commitment to work, time and travel. If anyone is
interested (no commitment yet) in serving on the ISO delegation,
please contact me; Mathis, Gabriel, and Clinger have already
expressed their interest.]
[The acting chairs are to make sure that the members of their
group communicate with each other. If it is appropriate that a
group set itself an agenda and select a leader, the acting chair
should make sure it happens. Each of these groups will be called
on for a BRIEF report at the next meeting. If that report will be
any more than just an affirmation of existence, please contact me
for scheduling.]
∂06-Jan-87 2157 edsel!bhopal!jonl@navajo.stanford.edu proposed purposes
Received: from NAVAJO.STANFORD.EDU by SAIL.STANFORD.EDU with TCP; 6 Jan 87 21:56:12 PST
Received: by navajo.stanford.edu; Tue, 6 Jan 87 21:55:27 PST
Received: from bhopal.edsel.uucp by edsel.uucp (2.2/SMI-2.0)
id AA01003; Tue, 6 Jan 87 21:48:53 pst
Received: by bhopal.edsel.uucp (1.1/SMI-3.0DEV3)
id AA16556; Tue, 6 Jan 87 21:46:18 PST
Date: Tue, 6 Jan 87 21:46:18 PST
From: edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)
Message-Id: <8701070546.AA16556@bhopal.edsel.uucp>
To: navajo!MATHIS%ADA20.ISI.EDU@navajo.stanford.edu
Cc: navajo!x3j13%SAIL.STANFORD.EDU@navajo.stanford.edu
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
[Sorry for the late entry of this comment -- I sent it out over two weeks
ago, and it got "bounced back" from some mail gateway at Stanford after
a few days of mailer problems; also, I've been "out of action" for
the past two weeks.]
Return-Path: <jonl>
Date: Fri, 19 Dec 86 11:27:59 PST
From: jonl (Jon L White)
To: navajo!MATHIS%ADA20.ISI.EDU
Cc: navajo!x3j13%SAIL.STANFORD.EDU
In-Reply-To: navajo!MATHIS@ADA20.ISI.EDU's message of 19 Dec 1986 05:46-PST
Subject: proposed purposes
At Dallas, there was question about the first paragraph wording:
". . . establish normative Common Lisp programming practice."
Just what does that mean? and how can a committee "establish" it?
Someone suggested that that phrase was a replacement for some nebulous
statement about "portability of programmers", or "portability of skills".
If that is indeed the goal, then it's hard to see how a committee can
"establish" it -- I remember a suggestion being offered to re-word the
whole sentence roughly as follows:
"It will codify existing practice, provide additional features to
enable the portability of code among diverse implementations,
and facilitate the establishment of normative Common Lisp
programming practice."
-- JonL --
∂15-Jan-87 1329 Mailer@XX.LCS.MIT.EDU Document 86-019
Received: from XX.LCS.MIT.EDU by SAIL.STANFORD.EDU with TCP; 15 Jan 87 13:29:03 PST
Received: from LIVE-OAK.LCS.MIT.EDU by XX.LCS.MIT.EDU via Chaosnet; 15 Jan 87 16:28-EST
Received: from GOLD-HILL-ACORN.DialNet.Symbolics.COM by MIT-LIVE-OAK.ARPA via DIAL with SMTP id 24905; 15 Jan 87 16:14:20-EST
Received: from BOSTON.Gold-Hill.DialNet.Symbolics.COM by ACORN.Gold-Hill.DialNet.Symbolics.COM via CHAOS with CHAOS-MAIL id 51643; Thu 15-Jan-87 14:31:21-EST
Date: Thu, 15 Jan 87 14:31 est
Sender: mike@acorn
To: x3j13@sail.stanford.edu
From: mike%acorn@mit-live-oak.arpa
Subject: Document 86-019
Note: You will be receiving hardcopy of the following from Bob Mathis.
----------------------------------------------------------------------
!
To: ANSI x3j13
From: Mike Beckerle, Gold Hill Computers
Date: 1/13/87
Subject: Document x3j13/86-019
Since my draft proposal which was hastily drawn up at the last x3j13
meeting, I have had time to reconsider several points in my proposal
for adding a few features to CL to support Higher-Order Functional
Programming. I have also decided to bring up the meta issue in this
forum.
The meta-issue is this: Would adding enough syntactic accommodation
to Common Lisp to make functional programming palatable defuse this
Lisp1 vs. Lisp2 debate enough? Or more optimistically, what level of
accommodation for programming with functionals would in fact defuse
this issue. For example, Would it be enough to provide the following:
Programs written in in a Lisp1 "educational/functional" dialect would
not be directly upwardly compatible with ANS Common Lisp; however,
the changes required would be straightforward to make and
syntactically convenient. (We know that they can't be automatic due
to use of EVAL.) I am particularly trying to address the issues of
Appendix B, section 6 of the "Issues..." paper.
What I'm trying to get at here is this: Why do people want a
"one-cell" lisp? Is it because it promotes/allows effective
programming using higher-order functions (style), because it is
more consistent/cleaner and therefore easier to understand and
teach (conceptual economy), because they are more familiar with a
one-cell lisp than a two cell lisp (momentum), because of a
purely aesthetic view that one cell is "better" (aesthetics),
because they don't like the name-capture problems of
common-lisp's so called "non-hygienic" macros (macrophobia), or
finally because they want political clout (politics).
My approach addresses that the push for lisp1 is due at least
partially to aesthetics but primarily is due to the style issue.
The following is a proposal for adding a small number of features
to Common Lisp to accommodate programming using higher-order
functions, or functionals. Functional programming is much easier
in a Lisp1 dialect than a Lisp2 dialect since functional
programming makes extensive use of functions as values. Common
Lisp's current (Funcall ...) and (Function ...) or #' syntax
makes functional programming particularly awkward. In addition
the fact that one cannot write an application which produces a
function in the car of a list representing an application is a
pain. [let's call this the "((f g) h)" problem.] These features
are intended to accommodate the functional style, without changing
the language too radically from the current status defined in
CLtL.
---------------------------------------------------------------------
!
Document x3j13/86-019
Accommodating Functional-Style Programming in Common Lisp.
Mike Beckerle
Gold Hill Computers
Jan. 6, 1986.
One of the primary motivations for use of Lisp1 dialects is the
ease of higher-order programming. Many of the examples of
effective programming practice in Lisp1 given in the "Issues of
Separation in Function and Value Cells" paper recently discussed
by x3j13 at the Dec. '86 meeting are exactly of this type.
Unfortunately, macro programming in Lisp1 dialects is not well
understood and is a subject of current research; nevertheless
macro programming is heavily entrenched in the Common lisp world.
As a result, the approach advocated in this proposal is to
provide some standard operators and macros which make programming
using higher-order functions in Common Lisp significantly easier.
The Changes to CL as defined in CLtL are enumerated here, after
which there are some examples.
Change 1:
To section 5.2. Functions
Function call forms should be changed to allow the lisp1 like
syntax of:
((f g) h)
((lambda (x) x) #'(lambda (y) y)) 10) => 10.
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
beginning with something other than LAMBDA it should be
interpreted as an application itself.
The forms above should, in every sense of the word except syntax,
be equivalent to:
(funcall (f g) h)
and
(funcall ((lambda (x) x) #'(lambda (y) y)) 10))
in the current CL as per CLtL.
Essentially, whenever symbols are used as functions, their
function-cell definitions are used. Lambda expressions and
function applications can also be used as functions. Lambda
expressions evaluate to functions. Function applications must
evaluate to either functions or symbols. If they evaluate to
symbols, then (recursively) the function definition of that
symbol is used.
The CL spec can explain the purpose of this special treatment for
function-positioned symbols in terms of the name-capture problem
of macros. Inadvertant name capture is, after all, the only real
reason for the special distinction for funtion-positioned symbols.
!
Change 2: Section 7.1.1.
The FUNCTION special form will be optional in front of
lambda expressions regardless of where they appear in a
program text. (The obvious exception for within quoted lists
obviously applies here, but isn't worth mention.)
It is as if the following definition was part of the CL system
(Defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
The FUNCTION special form is needed only to distinguish between
the function and value of symbols which are either globally
referenced or locally bound using one of FLET, LABELS, MACROLET,
parameter passing, LET, LET*, and MULTIPLE-VALUE-BIND.
!
Change 3: Section 20.2
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
E.g.,
(symbol-value 'mapcar) => #<compiled-function 1234>
(symbol-function 'mapcar) => #<compiled-function 1234>
This allows use of the CL symbols which name CL functions in
variable position without need for the FUNCTION special form as
in (mapcar list '(a b c) '(d e f)). If the value of the variable
"list" is locally bound to a function, possibly using let, then
the local definition will be used in accordance with the rules of
lexical scoping.
The primary change this requires is the renaming of certain
symbols of significance to the standard read-eval-print loop.
I suggest that the following renamings be used:
+ => +1
++ => +2
+++ => +3
- => -- or _ ;; this one's difficult to get a nice name for!
* => *1
** => *2
*** => *3
/ => /1
// => /2
/// =? /3
The behavior of these variables would be identical to the current
behavior of the old-named variables. I consider this change to
be simply cosmetic, aesthetic, etc. No program of any quality
(other than those written as read-eval-print loops by
implementors) ever uses these variables. (Unfortunately, the
Peter Principle dictates that the least significant point always
gets the most debate, so I'm prepared for absolute tirades on
this one! Please restrain yourselves!!!!!)
!
Change 4: Section 7.11. Use of Higher-order Functions
Organizationally, this seems to belong in the chapter 7
discussion, so I've proposed a new section for that chapter
in lieu of any guidelines for how to present standards proposals.
The text as a preliminary draft follows:
"Common Lisp provides some support for programming using higher-
order functions. These allow the programmer to partially hide the
distinction between function-cells and value-cells and to program
as if using a language where only one cell is associated with
each symbol. The objective is to make the syntax of higher-order
programs easier to read and understand. The abstraction that this
creates is not complete; it is possible for programs to detect
that there are separate function and value cells even when these
abstractions are used; however, the syntactic convenience of
using these forms where they are applicable is significant.
FUNCTIONAL Vars* {form}* [Macro]
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
For example:
(defun doublemap (f g)
(functional (f g)
(lambda (list) (f (g (mapcar f list)
(mapcar g list))))))
(defun y (f) ;; the paradoxical combinator
(functional (f)
((lambda (x)
(functional (x)
(f (x x))))
(lambda (x)
(functional (x)
(f (x x)))))))
Here, notice that "f" and "g" are used both as variables
representing functions, and also as functions, as if defined by
FLET or LABELS.
One possible definition for FUNCTIONAL is:
(defmacro functional (vars &body body)
(let* ((bindings (mapcar #'(lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
Implementation note: FUNCTIONAL can also be implemented
using MACROLET.
Care is required if FUNCTIONAL is used in programs which perform
side-effects on symbols via SYMBOL-FUNCTION or SYMBOL-VALUE. The
behavior of the resulting program can be difficult to predict."
!
Change 5: Section 7.1.1. (again)
Note: The following is the least kosher aspect of this proposal,
but I am including it anyway. Once again it is written as an
addition to section 7.1.1. Its intended use is for defining new
named functions which will be associated with both function and
value cells of symbols, thereby forming a consistent extention.
In general, use of side-effects within higher-order programs is
extremely tricky; one tends to program in a pure style out of
necessity.
SYMBOL-CONTENTS symbol [Function]
In order to facilitate programming in the functional style it is
often useful to ignore the function-cell/value-cell aspect of
symbols. Symbol-contents, if used consistently throughout an
entire program can facilitate this style of programming.
The function Symbol-contents can be used to extract or replace the
value of a symbol in a manner which is indifferent to the
normal CL distinction between function cells and value cells.
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
Symbol-contents cannot access nor assign (using setf) the value
of local symbol or function definitions created using let, flet, labels,
let*, etc. Only the global value can be accessed or modified.
It is an error to execute code which calls a function named by a symbol
where that symbol has been assigned a value other than a function object
via setf of symbol-contents.
(defun foobar (x) x)
(symbol-contents 'x) => #<unbound>
(setf (symbol-contents 'x) (lambda (x) (+ x x)))
(symbol-contents 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-function 'x) => #<function-object (lambda (x) (+ x x))>
(symbol-value 'x) => #<function-object (lambda (x) (+ x x))>
(eq (symbol-function 'x) (symbol-value 'x)) => T
--------------------------------------------------------------------
!
Use of the Higher-order function extensions to CL.
To show the utility of these abstractions in higher order
programming, it is important to look at some example programs.
Hence, I have rewritten the examples in Appendix B of
the "Issues of Separation in Function Cells and Value Cells"
using Common Lisp with the proposed extensions.
;;;---------------------------------------------------------------------
;;; from Appendix B: "High-Order Procedures for Functional Abstractions"
;; our macro for making functional programming easier.
(defmacro functional (vars &body body)
(let* ((bindings (mapcar (lambda (name)
`(,name (&rest args) (apply ,name args)))
vars)))
`(flet ,bindings
,@body)))
;; a macro which obviates #' notation.
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
;; the symbol-contents function and its setf.
(defun symbol-contents (name)
(symbol-value name))
(defun set-symbol-contents (name value)
(setf (symbol-value name) value)
(setf (symbol-function name) value))
(defsetf symbol-contents set-symbol-contents)
;; a DEFINE macro, syntactic sugar to make the examples
;; more scheme-like. Doesn't put implicit blocks on lambda's,
;; doesn't handle local defines. This could be done, but we won't bother
;; here.
(defmacro define (name value)
`(setf (symbol-contents ',name) value))
;; misc.
(defun null? (x) (null x))
(defun future (x) x)
(defun assq (x y)
(assoc x y :test 'eq))
;;--------------------------------------------------------------------
!
;; The example programs.
;; these have been translated slightly from Scheme to Common Lisp
;; plus my suggested extentions.
(define sum
(lambda (f a next b)
(functional (f next)
(if (> a b)
0
(+ (f a)
(sum f (next a) next b))))))
(define integral
(lambda (f a b dx)
(functional (f)
(* (sum f (+ a (/ dx 2)) (lambda (x) (+ x dx)) b)
dx))))
(define map
(lambda (f x)
(functional (f)
(if (null x)
nil
(cons (f (car x))
(map f (cdr x)))))))
(define reduce
(lambda (f l)
(functional (f)
(if (null? (cdr l))
(car l)
(f (car l)
(reduce f (cdr l)))))))
(define pairs
(lambda (x k)
(functional (k)
(if (or (null? x) (null? (cdr x)))
(k nil x)
(pairs (cddr x)
(lambda (p r)
(k (cons (list (car x) (cadr x))
p)
r)))))))
(define reduce
(lambda (f x)
(functional (f)
(pairs x
(lambda (p r)
(if (null? p)
(car r)
(reduce f
(append (map (lambda (z)
(future (apply f z)))
p)
r))))))))
(defstruct (table-abstraction
(:constructor make-table-abstraction
(maker looker-up inserter))
(:conc-name nil))
maker looker-up inserter)
(defun hashfunction (n)
(lambda (x)
(mod (sxhash x) n)))
(define hashify
(lambda (n table-abstraction)
(let ((hash (hashfunction n))
(bucket-make (maker table-abstraction))
(bucket-lookup (looker-up table-abstraction))
(bucket-insert! (inserter table-abstraction)))
(functional (hash bucket-make bucket-lookup bucket-insert!)
(let ((make
(lambda ()
(let ((hashtable (make-array n)))
(dotimes (i n)
(setf (aref hashtable i)
(bucket-make)))
hashtable)))
(lookup
(lambda (key table)
(bucket-lookup key
(aref table
(hash key)))))
(insert!
(lambda (key table value)
(bucket-insert! key
(aref table (hash key))
value))))
(make-table-abstraction make lookup insert!))))))
(defun make-entry (key value) (cons key value))
(defun set-value! (vcell value) (rplacd vcell value))
(define alist-table-abstraction
(make-table-abstraction
(lambda () (list '*alist-table*))
(lambda (key table)
(cdr (assq key (cdr table)))) ;; alist of cons pairs
(lambda (key table value)
(let ((vcell (assq key (cdr table))))
(if vcell
(set-value! vcell value)
(rplacd table
(cons (make-entry key value)
(cdr table))))))))
(define hash-table-of-alists-abstraction-generator
(lambda (n) (hashify n alist-table-abstraction)))
(define hash-table-of-alists
(hash-table-of-alists-abstraction-generator 16))
(define two-level-hash-table-abstraction-generator
(lambda (m n table-abstraction)
(hashify m (hashify n table-abstraction))))
(define two-level-hash-table-of-alists-abstraction-1
(two-level-hash-table-abstraction-generator
128 256 alist-table-abstraction))
;;-----------------------------------------------------------------
My observation is that using the FUNCTIONAL abstraction along with the
ability to perform applications which syntactically look like "((f g) h)"
makes the enhanced CL version pretty close to the Lisp1 version at least
as far as syntactic aesthetics are concerned.
∂15-Jan-87 2015 Moon@STONY-BROOK.SCRC.Symbolics.COM Document 86-019
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 15 Jan 87 20:15:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 44898; Thu 15-Jan-87 23:13:42 EST
Date: Thu, 15 Jan 87 23:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Document 86-019
To: mike%acorn@MIT-LIVE-OAK.ARPA
cc: x3j13@sail.stanford.edu
In-Reply-To: The message of 15 Jan 87 14:31 EST from mike%acorn@mit-live-oak.arpa
Message-ID: <870115231337.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Thu, 15 Jan 87 14:31 est
From: mike%acorn@mit-live-oak.arpa
I don't know if X3J13 is the right mailing list for technical discussions,
but I'd like to offer a few comments on your proposal. To avoid contributing
to total mail overload, I will abbreviate your proposal as much as possible
when referring to it.
Change 1: Function call forms should be changed to allow the lisp1 like
syntax of: ((f g) h)
i.e., the "function" position of an application should be treated
specially only if it contains a SYMBOL. If it contains a list
it should be interpreted as an application itself.
I think this is a good idea. It's a kludge, of course, and creates a
small inconsistency in the language (allowing list forms but not symbol
forms), however I think the ratio of benefit to harm is favorable.
Maclisp on the pdp-10 used to have a feature similar to this, but it was
removed because it caused a lot of problems. I believe the problems can
be traced to the fact that it allowed the result of evaluating a list or
efunctuating a symbol to be another list, which was then evaluated. The
question is, in what lexical scope should that list be evaluated. Your
proposal avoids this problem by forbidding repeated evaluation.
Your proposal allows repeated efunctuation (that is, the result of
evaluating a list can be a symbol, which is then efunctuated) and you
don't specify in what lexical environment the symbol is to be
efunctuated. CLtL is not very clear on this point; p.107 says that
APPLY efunctuates in the global lexical environment if given a symbol,
but otherwise the issue is not addressed as far as I can see. This
feature may not be essential to your proposal; you might want to remove
it.
(For those who haven't seen the term before, "efunctuate" is what the
FUNCTION special form does.)
Change 2: It is as if the following definition was part of the CL system
(defmacro lambda (&rest forms)
`(function (lambda ,@forms)))
This is definitely a good idea and causes no problems.
Change 3:
For syntactic convenience, the value cell of all CL symbols
which are defined as functions are defined to contain
the function object as well as the function cell.
I don't think this is a good idea, because it creates an artificial
distinction between built-in CL functions and functions defined by
the user with DEFUN or LABELS. If the rule of storing the definition
in both cells applies to the latter type of functions too, then
we would just have Lisp1.
Change 4:
The Functional macro is used to create an environment where the
variables in the list "Vars" can be used both as variables and
in function position within the body forms without need for the #' or
(function ...) operator, nor use of (funcall ...).
This is a good idea. To me it seems that having this eliminates the
need for your change 3.
Change 5:
Symbol-contents returns the contents of the value-cell of the
symbol when used as an accessor. When used as an assigner
(with setf); however, the value assigned is placed into both
the function-cell, and the value-cell.
This stands or falls with change 3. Again, I think change 4 is
a better approach.
∂16-Jan-87 0822 FAHLMAN@C.CS.CMU.EDU Document 86-019
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 16 Jan 87 08:21:50 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Fri 16 Jan 87 11:21:29-EST
Date: Fri, 16 Jan 1987 11:21 EST
Message-ID: <FAHLMAN.12271401438.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
To: "David A. Moon" <Moon@SCRC-STONY-BROOK.ARPA>
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU, x3j13@SAIL.STANFORD.EDU
Subject: Document 86-019
In-reply-to: Msg of 15 Jan 1987 23:13-EST from David A. Moon <Moon at STONY-BROOK.SCRC.Symbolics.COM>
This discussion should probably be on the Common-Lisp mailing list, but
since I'm responding to Moon's mail to this list, I'll do it here.
I agree totally with Moon on this one -- I was just about to write a
reply with essentially the same content as his, supporting the idea
except for parts 3 and 5.
If the goal is to make functional-style programming easier without
disrupting Common Lisp too badly, I think your proposals (minus numbers
3 and 5) do the job about 90% as well as a move to Lisp1. For those
people whose goal is to merge Common Lisp with Scheme and/or Eulisp,
then only a move to Lisp1 will do. However, unless great progress is
made on the macro issue and on ways of making the conversion less
painful, I think that a move to Lisp1 is unlikely; less radical
proposals such as yours are definitely worth considering.
I like this much better than the &function idea, by the way. that
seems very confusing and irregular to me.
-- Scott
∂16-Jan-87 1124 Masinter.pa@Xerox.COM Re: Document 86-019, &function, etc.
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 16 Jan 87 11:24:34 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 JAN 87 11:24:00 PST
Date: 16 Jan 87 11:24 PST
From: Masinter.pa@Xerox.COM
Subject: Re: Document 86-019, &function, etc.
In-reply-to: various
To: x3j13@sail.stanford.edu
Message-ID: <870116-112400-2364@Xerox>
These proposals fail to meet what I believe is the primary goal of those
who want 1-lisp over 2-lisp, namely, to simplify and make more
consistent the programming language semantics, to reduce the number of
different kinds of references in the language.
Instead, they do the opposite. While superficially bearing some
resemblance to 1-lisp, there are more rules for evaluation rather than
fewer, the description of the language and its semantics is complex,
there are odd exceptions. (For example, in the
funcall-if-car-of-form-is-list proposal, what if the car of the form is
a macro? A macro that expands to a symbol? To a lambda?).
It does no good to pick some minor syntactic feature of 1-lisp,
implement that, and ignore the basic principle.
∂16-Jan-87 2155 willc%tekchips.tek.com@RELAY.CS.NET Re: Document 86-019
Received: from RELAY.CS.NET by SAIL.STANFORD.EDU with TCP; 16 Jan 87 21:55:29 PST
Received: from tektronix.tek.com by csnet-relay.csnet id ab04827;
17 Jan 87 0:43 EST
Received: by tektronix.TEK.COM (5.31/6.18)
id AA04079; Fri, 16 Jan 87 21:25:51 PST
Received: by tekchips.TEK (5.31/6.16)
id AA12223; Fri, 16 Jan 87 14:56:26 PST
Message-Id: <8701162256.AA12223@tekchips.TEK>
To: x3j13@SU-AI.ARPA
Cc: mike%acorn@LIVE-OAK.LCS.MIT.EDU
Subject: Re: Document 86-019
In-Reply-To: Your message of Thu, 15 Jan 87 14:31 est.
<8701160757.AA02526@tekchips.TEK>
Date: 16 Jan 87 14:56:21 PST (Fri)
From: willc%tekchips.tek.com@RELAY.CS.NET
Mike Beckerle asked some interesting questions and suggested some possible
answers. Ultimately, he is asking for a philosophy of programming language
design. Here's mine.
* * *
Programming is hard because it's hard to know what you want the machine
to accomplish (the problem), and it's hard to know how to accomplish it
(the algorithm). If you knew these two things, it ought to be easy to
program the machine to do what you want.
It usually isn't. The reason is that you have to learn all sorts of arcane
things about the computing environment and programming language that you
use. These details have nothing to do with the problem you're trying
to solve. Even so, they may be almost as difficult to master.
Most people, being reasonable, don't try to master their programming
language completely, particularly if their programming language is big
and complicated. In my experience, the main thing that a programming
language can do for these people is to be consistent with a simple mental
model that they can use without getting into trouble. Extra features
that help people get their work done more easily are nice, but it is more
important that the language not get in their way. It is most important
that the language not be full of nasty surprises for its users.
This principle of programming language design is sometimes known as the
"Law of Least Astonishment", in waggish recognition of the fact that even
the best design efforts are ad hoc in part. Its motivation is very
pragmatic, its application very practical. It says that simplicity,
elegance, and aesthetics pay off.
* * *
In answer to some of Mike's specific questions, people prefer a single-
environment Lisp because of style, conceptual economy, and aesthetics; I
see little difference between conceptual economy and aesthetics, which is
perhaps a clue to my sense of aesthetics. Inertia can't be the reason,
since most of us who prefer the single environment were once more familiar
and comfortable with two-cell Lisps. Macros don't have anything to do with
this issue, so macrophobia can't be the reason; if anything, the problems
with Common Lisp-style macros are exacerbated by a single environment.
Speaking for myself, politics isn't the reason I prefer a single
environment; rather my preference for a single environment, the current
preponderance of political clout on the side of multiple environments,
and the use of that clout in the current push for Lisp standards are the
reasons I myself now seek political clout.
* * *
Mike's other question asks whether enough syntactic sugar could be added
to Common Lisp to make functional programming palatable. Well, Common
Lisp certainly could be improved in this respect, and I second David
Moon's remarks on changes 1 and 2.
As for changes 3, 4, and 5, these changes seem designed to make it possible
to program as though Common Lisp were a Lisp1 dialect, but they only go
part of the way. You might be able to go all the way by doing things like
defining the LAMBDA macro so it automatically wraps an equivalent of the
FUNCTIONAL macro around its body, by defining a SET! special form that
assigns to both the value and functional bindings (which, by the way, can't
easily be written in Common Lisp as it stands because only global functional
bindings can be assigned), and so on. This would amount to implementing
a Lisp1 sublanguage inside Common Lisp. Unless you're willing to go
all the way to that Lisp1 sublanguage, I think it's a bad idea to try
to paper over the fact that Common Lisp has multiple environments.
If the changes go only part of the way, and we teach people to use the
proposed syntax and encourage them to think about Common Lisp as though
it is a Lisp1 dialect, then they will probably end up getting burned
even more often than they do now. Even people who understand full well
that Common Lisp has multiple environments might slip into the cozier
Lisp1 mode of thought and get burned by the Lisp2 reality.
It's the law of least astonishment: A Lisp2 dialect that looks like a
Lisp1 dialect 98% of the time may be worse than a straightforward Lisp2
dialect.
Peace,
William Clinger
∂22-Jan-87 1732 RPG March X3J13 Meeting in Palo Alto
To: x3j13@SAIL.STANFORD.EDU
X3J13 Meeting
3/16/87 - 3/19/87
Palo Alto, CA
The third meeting of X3J13 will be held from 1pm, Monday, March 16, 1987
until noon, Wednesday, March 18, 1987, at the Hyatt Rickeys (not to be
confused with the Hyatt Palo Alto across the street) in Palo Alto, CA.
Meetings on Monday and Tuesday will be in the Camino Ball Room C and on
Wednesday the meeting will be in the Executive Conference Room. Come
early, California is beautiful in March.
A block of rooms is available at the Hyatt Rickeys. The rate will be $92 a
night (plus tax). If you prefer, they have rooms available for non-smokers
(ahh, a room never touched by smoke). Please check the appropriate dates
and supply a credit card number if you wish to have the room guaranteed.
Check in time is 3:00pm. Check out time is 12:00 noon. I will be taking
reservations until 2/15/87. After that time please contact Hyatt Rickeys
directly at (800) 228-9000 for reservations and changes. Be sure to
mention ``Standards Committee X3J13'' or ``Lucid.'' Reservations must be
received by the hotel no later than 2/15/87 to receive the discounted rate.
Refreshments will be available during the morning and afternoon sessions.
Lunch has been arranged for Tuesday, March 17. If you have dietary
restrictions please complete the appropriate section below.
The cost per person for food service and conference room rental is $55.00.
Please include a check for this amount, payable to Lucid, with the
registration form.
Delta Airlines has agreed to give us a 35% discount to San Francisco. Call
Delta (or have your travel agent call) toll free at 1 (800) 241-6760 daily
8:30am thru 8:00pm EST. Please refer to file number A0732 when calling.
Tickets must be purchased 14 days in advance, there is no minimum stay, and
the maximum stay is 14 days. Please confirm early as there is limited
seating.
I will be happy to arrange a group dinner at the Thai Garden (a different
eating experience) the evening of March 16 with an extra cost. If you are
interested, please note this in the appropriate space below.
N San Francisco Airport
W E |
S | | 101
------------------------------------------92
| |
| |
| |
| |
| | 101
Foothills | | San Francisco Bay
| |
| |
| |
|X Hyatt Rickey |
| |
|El Camino Real |
| |
Los Altos ----------------------------------------San Antonio Road
| |
| |
Directions from San Francisco airport to Hyatt Rickeys: Take 101 south to
San Antonio Road (about 25 minutes in non-rushhour traffic). Take San
Antonio Road exit marked Los Altos, heading toward the hills. Turn right
on El Camino Real. The hotel is on the right at 4219 El Camino Real, Palo
Alto, CA 94306 (415) 493-0800. Hertz, Avis and National car rentals are
within 1 block.
A shuttle service is available though Airport Connection for $12.00.
Pickup points are located directly outside each terminal baggage claim area
at the center traffic island. Shuttle will stop at each blue striped
pillar. The shuttle stops in Menlo Park, Standford and then Hyatt Rickeys.
The schedule from San Francisco Airport to Palo Alto follows:
* *
LV Menlo Stan- Palo Sunny- San ARR
SFO Park ford Alto vale Jose SJC
7:01A 7:20A 7:35A 7:40A 8:00A 8:25A 8:30A Daily
8:16A 8:40A 8:50A 8:55A 9:20A 9:40A 9:45A Ex. Sat
9:11A 9:35A 9:42A 9:46A 10:05A 10:30A 10:35A Daily
11:00A 11:25A 11:30A 11:35A 12:01P 12:25P 12:30P Ex. Sat
12:01P 12:25P 12:30P 12:35P 1:00P 1:25P 1:30P Daily
1:00P 1:25P 1:30P 1:35P 2:00P 2:25P 2:30P Ex. Sat
2:01P 2:30P 2:35P 2:40P 3:10P 3:40P 3:45P Daily
3:06P 3:35P 3:40P 3:45P 4:10P 4:40P 4:45P Ex. Sat
4:01P 4:30P 4:35P 4:40P 5:05P 5:35P 5:40P Daily
5:20P 5:50P 5:55P 6:00P 6:25P 6:50P 6:55P Ex. Sat
6:50P 7:20P 7:25P 7:30P 7:50P 8:15P 8:20P Daily
8:40P 9:05P 9:10P 9:15P 9:40P 10:00P 10:10P Ex. Sat
10:10P 10:40P 10:45P 10:50P 11:15P 11:35P 11:45P Daily
Shuttle service from Palo Alto to San Francisco Airport:
* *
LV SJC Sunny- Palo Stan- Menlo AR
San Jose vale Alto ford Park SFO
5:25A 5:30A 5:40A 6:08A 6:22A 6:27A 7:00A Daily
6:15A 6:20A 6:35A 7:08A 7:25A 7:30A 8:15A Ex. Sat
7:25A 7:30A 7:45A 8:13A 8:32A 8:37A 9:10A Daily
8:25A 8:30A 8:45A 9:13A 9:32A 9:37A 10:10A Ex. Sat
9:40A 9:45A 9:55A 10:23A 10:37A 10:42A 11:15A Daily
10:30A 10:35A 10:45A 11:08A 11:22A 11:27A 12:05P Ex. Sat
12:25P 12:30P 12:40P 1:08P 1:22P 1:27P 2:00P Daily
1:25P 1:30P 1:40P 2:08P 2:22P 2:27P 3:05P Ex. Sat
2:25P 2:30P 2:40P 3:08P 3:22P 3:27P 4:00P Daily
3:40P 3:45P 3:55P 4:25P 4:44P 4:49P 5:19P Ex. Sat
4:55P 5:00P 5:15P 5:45P 6:05P 6:10P 6:40P Daily
6:50P 6:55P 7:05P 7:30P 7:45P 7:50P 8:20P Ex. Sat
8:15P 8:20P 8:30P 8:55P 9:10P 9:15P 9:45P Daily
Feel free to contact me if you have any questions.
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
edsel!jlz@navajo.stanford.edu
(415) 329-8400
X3J13 March Meeting Registration Form
Please include check for $55.00 payable to Lucid, Inc. mail to:
Jan Zubkoff
Lucid, Inc.
707 Laurel Street
Menlo Park, CA 94025
(415) 329-8400
Name: _____________________________________________________________
Institution: ______________________________________________________
Street Address: ___________________________________________________
City: ________________ State: ___ Phone: ________________________
Net-Address: ______________________________________________________
Reservations: Mar 15: ___ Mar 16: ___ Mar 17: ___
___ single (1 person) ___ double (2 persons, 1 bed)
___ twin (2 persons, 2 beds) ___ triple (three persons, 2 beds)
The $92.00 room rate is only guaranteed for reservations received by
February 15.
Credit Card: ___ AMEX ___VISA ___ Mastercard ___Diners ___CB
Number: ___________________________________________ Exp ____________
Lunch 3/17: yes _______ no _______
Dietary Restrictions:_______________________________________________
Dinner at Thai Garden 3/16: yes _______ no _______
-rpg-
jlz